COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.NEWSS GENERAL SYSTEM OUTLINE
C00006 00003	.NEWSSS SOFTWARE
C00012 00004	.com: NEWSS THE AL COMPILER
C00019 ENDMK
C⊗;
.NEWSS GENERAL SYSTEM OUTLINE

The actual version of AL which we will implement is related
to our current hardware and software capabilities.
The following sections describe the overall system from a general
point of view.

.NEWSSS HARDWARE

	Currently  two  Stanford  Electric  Arms,   built  by  Victor
Scheinman [Scheinman], are available.  They are called YELLOW and BLUE.  Each has
six joints  and a hand  that can  open and  close.   The joints  are
controlled by  electric motors; each joint has both position
and velocity feedback.
Motor  drives are sent from the computer to
the arm via a  digital-to-analog converter (D-to-A); feedback  signals are
routed through an analog-to-digital converter (A-to-D) back to the computer.

	There are two computer-controlled cameras. The 
computer can control the pan, tilt, focus, iris, filter, and zoom
(or lens turret) on each camera.

	Various others devices are designed and implemented as needed.
We use tools, jigs and special markings for several purposes:
to render a task possible (an example is the arm itself), to improve
efficiency (the mechanical screwdriver), and to overcome some of our
sensory and mechanical limitations (the screw dispenser).
Currently we have an electrically powered screwdriver, a pneumatic
vise, and an electrically controlled turntable.  The screwdriver can
be picked up by an arm and operates in either direction over a range
of speeds.  The vise can be opened or closed; soon there will be
a way to servo it to a specified opening.  The computer can position
the turntable to any rotation (within .5 degrees).  As such
devices are built, they will be interfaced to the A-to-D, the runtime programs
told how to control them, and the language extended to include syntax
to describe how to use them.

	AL  resides on two  computers: The PDP-10  for all planning,
and a PDP-11/45 for the execution of the plans.  The former is run  as a
timesharing computer  (under a  modified DEC  system); the  latter is
operated  in  stand-alone mode under  the AL  runtime system.
 Each
computer is capable of generating an interrupt in the  other, and the
PDP-10 has complete control over the PDP-11 console and unibus.
It is not certain exactly what the minimum runtime computer configuration
will be; we use floating point and memory management, but it is not
clear that this is altogether necessary.


.NEWSSS SOFTWARE

	See {NEWFIG Overall system, FULL, sis←} for a picture of the
system. 

	The SUPERVISOR is the top level of AL.  It runs on
the timesharing computer
 and provides an interface between the user and the other
parts of the system: 1) listening to the user's console and
interpreting input in a simple command language; 2) controlling the
compiler, starting it and relaying its error messages back to the
user; 3) signalling the loader when it is necessary to place compiled
code into the mini; 4) handling the runtime interface to the mini. 
Each of these subsidiary modules is discussed below. 

	The USER sits at a console and makes requests of AL.  These
fall into several categories: compilation, loading, execution of
programs, debugging of code, requesting of status information, asking
for immediate arm motion, saving and restoring the state of the world
at safe points, requesting explanation of certain compiler decisions. 
There are two different consoles at which a user can sit:
one is connected to the timesharing computer,
through which she can speak to the supervisor
and all the parts of AL residing on the timesharing
computer; the other is connected
to the mini, and through it the user can investigate the runtime
system and cause modifications.

	The COMPILER reads AL programs from files (or, optionally,
directly from the user's console) and produces load modules.  The
compiler is divided into three phases: The PARSER, the EXPANDER, and
the TRAJECTORY CALCULATOR. The compiler is discussed in detail in
the next section and is pictured in 
{newfig The AL compiler,FULL,cfg←}.

	The LOADER takes the load modules prepared by the compiler
and enters them into the mini's runtime system.  Address relocation
and linking are done at this time. The loader also sets up the data
area in the runtime interface in the timesharing
computer; this data includes
output strings, procedure linkages, and information necessary for
diagnostic purposes during runtime.  Loading is often done in a
partially incremental fashion, installing new code following
previously loaded code.  

	The RUNTIME INTERFACE, which resides in the
timesharing computer, is charged with initiating the mini
program, fielding procedure calls from the running program to
procedures on the timesharing machine,
returning values from these procedures, and
fetching values from the mini for debugging purposes.  The
interface has the power to interrupt the execution of the program and
to modify the status of the runtime system, for example, by patching
in additional program, or modifying the values of some variables.
This allows the user to control the program through the timesharing
computer.

	The RUNTIME SYSTEM is the set of programs which reside in the
mini.  This system includes kernel programs for time-slice cpu
sharing and process control and a set of dynamically created
processes.  These are of three basic types: a) An INTERPRETER
examines the code prepared by the compiler and executes the numeric
computations requested.  When a move is to be started, the
interpreter creates a servo for each joint and waits until all these
servos are finished.  b) A SERVO handles the motion of one moving joint. 
c) A CONDITION-MONITOR repeatedly examines certain conditions
(whatever the programmer has specified).  If it should discover that
its condition has occurred, it creates an interpreter to take
appropriate action.  
The runtime system also includes routines for communication with the
runtime interface in the timesharing computer.


.com: NEWSS THE AL COMPILER

The AL compiler is built of three parts: the parser, the expander,
and the trajectory calculator.  These are depicted in {FIGREF cfg}.

.NEWSSS PARSER

	The PARSER  reads source code  from either  the console or  a
file.    Its  purpose is  to  form  parse trees  and  do  some simple
manipulations,  such as assigning line numbers,  causing  listings to
be  directed to  the appropriate  file (if  desired), expanding  text
macros,   and keeping a primitive symbol table.  If a syntax error is
discovered,  it  informs the  supervisor,  which  will give the  user
several  options,  including  aborting the compilation,  making local
modifications on  the  spot,   or  switching temporarily  to  a  text
editor.  

.NEWSSS EXPANDER  
  
The EXPANDER shares with the trajectory calculator the responsibility
for turning parser output into code interpretable by the runtime
system.  Its main functions are to maintain a model of the
expected runtime state at each point in the program and to use this
model to resolve a number of compile-time decisions.  The information
kept includes planning values,
object descriptions, relations
between objects, endpoint constraints on particular trajectories, and
much more.  Simple uses of this information include providing
the trajectory calculator with essential data and resolving
conditional compilation requests.  Beyond this, the expander
has principal responsibility for filling in the details required
to turn calls on various high and intermediate level primitives
into runnable manipulation programs.  It therefore
contains a number of quite specialized routines with considerable
knowledge about the domain of mechanical assembly, as well as a number
of more general mechanisms for coordinating the specialists.

The expander supplies to the trajectory calculator a structure which is
very similar to the parse trees it
accepts as input.  However, no choices are left; all values have been
explicitly specified.

.NEWSSS TRAJECTORY CALCULATOR

	The  TRAJECTORY  CALCULATOR  takes  the   expanded  code  and
computes  the  required   trajectories  for  the  arms.    Tables  of
interpretable  code are  generated    for  handling  arithmetic  and
assignment operations,   condition  monitoring,   and affixment structure
building  operations  (the  runtime system  keeps  track  of physical
attachment of  objects).   For  motions,   detailed tables are
emitted specifying  how each joint  of each arm  is to behave,   what
computations to  make  at  run-time for  the  modification  of  these
trajectories to bring them into correspondence with the current state
of the world (for it happens often that objects are not exactly where
they were planned to be),  and what conditions to monitor during  the
motion.

	The trajectory calculator also is used to provide information
to the expander.   For instance,  it can  predict the runtime effects
of a given modification of a planned trajectory.  This information is
useful to the expander for deciding  how many different trajectories
must be planned for a given motion request, for estimating the feasibility
of a given motion, and for other similar purposes.

	There are  several errors which the trajectory calculator can
detect.  A request might take  the arm outside its range, or force  a
joint to exceed its velocity limits.  It may discover that there is a
possibility of collision between the two arms,  or between the arm and
some object on the table.  In order to carry out these tests,  it may
request  assurance  from the  user  that some  object  lies within  a
certain region,  or it may give the user a warning.  The world  model
is  used for  much  of  this calculation.    At its  discretion,  the
trajectory calculator  may make some critical motions  very slow,  so
that an impending collision will be detected before it happens. 

	The output of the  trajectory calculator is stored in  binary
files,  for loading into the PDP11.